DevGuide 🇵🇸

إزاي تتعامل مع الـ State في مشاريع الفرونت إند؟ 💡
.
.
خليني أحكيلك سيناريو بسيط:

أنت شغال على UI لتطبيق إعلانات. في الصفحة الرئيسية فيه زرار بيعرض modal، وفي نفس الوقت فيه قائمة إعلانات بترجع من API، ولما تضغط على إعلان بتروح على صفحة التفاصيل.

دلوقتي الـ modal ده لو تحكمت فيه بـ useState مثلًا في نفس الـ component؟ تمام.
بس الإعلانات؟ محتاج تجيبها من API وتخزنها؟ هتضيفها فين؟
ولو صفحة التفاصيل محتاجة تشوف نفس الداتا؟ هتعمل إيه؟
ولو عندك مستخدم مسجل دخول، ومحتاج كل الصفحات تعرف حالته؟

هنا تبدأ قصة الـ State Management، وتحديدًا:

- هل الداتا دي تبقى locally؟
- ولا تكون في global state؟
ولا تفضل على الـ server وتجيبها كل مرة؟

تعال ندردش شوية عن إزاي تتعامل مع الـ State في مشاريع الفرونت إند...

———

✅ أنواع الـ State اللي ممكن تتعامل معاها:

1- Local State

مثل:

- الـ modal مفتوح ولا مقفول
- الـ tab اللي مفتوح
- الفورم فيه error ولا لا

بتستخدم معاه حاجات زي useState, useReducer, أو حتى useRef.

———

2- Global State

ده اللي بيكون مهم لأكثر من component أو حتى أكتر من صفحة.

مثل:

- بيانات المستخدم بعد ما يعمل تسجيل دخول
- اللغة المختارة
- محتوى الـ shopping cart

ممكن تتعامل معاه باستخدام:
Context API | Redux | Zustand | Jotai

———

3- Server State

يعني داتا راجعة من API وبتتغير دايمًا.

مثل:

- قائمة البوستات اللي بترجع
- الإعلانات
- بيانات المنتج

التعامل معاها الأفضل يتم من خلال:

- React Query
- SWR
- custom hooks using fetch

———

4- URL State

ده زي الـ query params والـ path variables.

مثل:

- ?search=react
- /products/123


بتحتاجه لما الصفحة تكون reactive بناءً على URL.

———

💡 إزاي تقرر تستخدم أي نوع منهم؟

اسأل نفسك 3 أسئلة:

1. الداتا دي مين محتاج يشوفها؟

- لو component واحدة تبقى local
- لو أكثر من component أو أكثر من صفحة تبقى global


2. هل الداتا دي راجعة من السيرفر؟

- لو أيوه تبقى server state
- لو لا يبقى ترجع لإجابة السؤال الأول


3. هل محتاج تعمل caching أو refetching؟

- لو أيوه ممكن تستخدم React Query/SWR
- لو لا يبقى الـ useEffect كفاية

———

✅ شوية نصائح من التجربة:

- بلاش تستعجل وتستخدم Redux، كتير بيستخدموه في حاجات صغيرة جدًا ممكن تتحل بـ Context أو حتى props.

- خلي الداتا اللي بتتغير كتير تفضل على السيرفر، وخلي الـ React Query تمسكها بدل ما تعملها global state manually.

- متخليش كل حاجة global، ده بيخلي الـ re-rendering يزيد والـ debugging بيكون أصعب.

- الـ Server State مش دايمًا محتاج يتحول لـ Global State، الـ React Query مثلًا بيخزنها وبيشاركها بين الـ components تلقائي، من غير ما تدخلها في Redux أو غيره.

- الـ Context ممتاز للحاجات اللي مش بتتغير كتير، زي الـ theme أو اللغة أو المستخدم اللي دخل مرة واحدة وخلاص.

———

اختيارك للـ state له تأثير مباشر على الـ performance، وكمان الـ maintainability، والـ DX بتاعك.

———

وفقكم الله لكل خير 🌿

www.tg-me.com/us/DevGuide 🇵🇸/com.the_developer_guide/5316

438 viewsJun 16 at 13:02

إزاي تتعامل مع الـ State في مشاريع الفرونت إند؟ 💡
.
.
خليني أحكيلك سيناريو بسيط:

أنت شغال على UI لتطبيق إعلانات. في الصفحة الرئيسية فيه زرار بيعرض modal، وفي نفس الوقت فيه قائمة إعلانات بترجع من API، ولما تضغط على إعلان بتروح على صفحة التفاصيل.

دلوقتي الـ modal ده لو تحكمت فيه بـ useState مثلًا في نفس الـ component؟ تمام.
بس الإعلانات؟ محتاج تجيبها من API وتخزنها؟ هتضيفها فين؟
ولو صفحة التفاصيل محتاجة تشوف نفس الداتا؟ هتعمل إيه؟
ولو عندك مستخدم مسجل دخول، ومحتاج كل الصفحات تعرف حالته؟

هنا تبدأ قصة الـ State Management، وتحديدًا:

- هل الداتا دي تبقى locally؟
- ولا تكون في global state؟
ولا تفضل على الـ server وتجيبها كل مرة؟

تعال ندردش شوية عن إزاي تتعامل مع الـ State في مشاريع الفرونت إند...

———

✅ أنواع الـ State اللي ممكن تتعامل معاها:

1- Local State

مثل:

- الـ modal مفتوح ولا مقفول
- الـ tab اللي مفتوح
- الفورم فيه error ولا لا

بتستخدم معاه حاجات زي useState, useReducer, أو حتى useRef.

———

2- Global State

ده اللي بيكون مهم لأكثر من component أو حتى أكتر من صفحة.

مثل:

- بيانات المستخدم بعد ما يعمل تسجيل دخول
- اللغة المختارة
- محتوى الـ shopping cart

ممكن تتعامل معاه باستخدام:
Context API | Redux | Zustand | Jotai

———

3- Server State

يعني داتا راجعة من API وبتتغير دايمًا.

مثل:

- قائمة البوستات اللي بترجع
- الإعلانات
- بيانات المنتج

التعامل معاها الأفضل يتم من خلال:

- React Query
- SWR
- custom hooks using fetch

———

4- URL State

ده زي الـ query params والـ path variables.

مثل:

- ?search=react
- /products/123


بتحتاجه لما الصفحة تكون reactive بناءً على URL.

———

💡 إزاي تقرر تستخدم أي نوع منهم؟

اسأل نفسك 3 أسئلة:

1. الداتا دي مين محتاج يشوفها؟

- لو component واحدة تبقى local
- لو أكثر من component أو أكثر من صفحة تبقى global


2. هل الداتا دي راجعة من السيرفر؟

- لو أيوه تبقى server state
- لو لا يبقى ترجع لإجابة السؤال الأول


3. هل محتاج تعمل caching أو refetching؟

- لو أيوه ممكن تستخدم React Query/SWR
- لو لا يبقى الـ useEffect كفاية

———

✅ شوية نصائح من التجربة:

- بلاش تستعجل وتستخدم Redux، كتير بيستخدموه في حاجات صغيرة جدًا ممكن تتحل بـ Context أو حتى props.

- خلي الداتا اللي بتتغير كتير تفضل على السيرفر، وخلي الـ React Query تمسكها بدل ما تعملها global state manually.

- متخليش كل حاجة global، ده بيخلي الـ re-rendering يزيد والـ debugging بيكون أصعب.

- الـ Server State مش دايمًا محتاج يتحول لـ Global State، الـ React Query مثلًا بيخزنها وبيشاركها بين الـ components تلقائي، من غير ما تدخلها في Redux أو غيره.

- الـ Context ممتاز للحاجات اللي مش بتتغير كتير، زي الـ theme أو اللغة أو المستخدم اللي دخل مرة واحدة وخلاص.

———

اختيارك للـ state له تأثير مباشر على الـ performance، وكمان الـ maintainability، والـ DX بتاعك.

———

وفقكم الله لكل خير 🌿

BY DevGuide 🇵🇸